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Abstract. MEG (/i^ ^^7) is an experiment dedicated to search for the /i^ 6^7 decay that is strongly 
suppressed in the Standard Model, but allowed in many alternative models and therefore very sensitive to 
new physics. The offline software is based on two frameworks. The first is REM in FORTRAN 77, which 
is used for the event generation and detector simulation package GEM. The other is ROME in C++, 
used for the readout electronics simulation Bartender and for the reconstruction and analysis program 
Analyzer. Event display in the simulation is based on GEANT3 graphic libraries and in the reconstruction 
on ROOT graphic libraries. Data are stored in different formats at various stages of the processing. The 
frameworks include utilities for I/O, database access and format conversion transparent to the user. 



PACS. 29.85.Fj Data analysis 

1 Introduction 

The MEG experiment at Paul Scherrer Institute (PSI) in 
Switzerland is searching for the rare decay /i+ e+7, 
employing a very intense (3 x 10^s~^) /i+ beam, which 
is stopped in a thin target at the center of the detector. 
MEG is a small-size collaboration 50 — 60 physicists at 
any time) with a life span of about 10 years. 
The collaboration started the software development in 
2002 after a few years of prototype studies, with the goal 
of being ready for data taking in a technical run foreseen 
after 3 years. Since the beginning, the tight time schedule 
and the limited human resource available, in particular in 
the offline architecture group, emphasized the importance 
of reusing software developed during the prototype stud- 
ies and exploiting existing expertise. Therefore great care 
has been devoted to provide a simple system that hides 
implementation details to the average programmer. That 
has allowed many members of the collaboration with lim- 
ited programming skill to contribute to the development 
of the software of the experiment. 

The detector consists of a Liquid Xenon Calorimeter for 
measuring the 7 momentum vector and timing and of a 
spectrometer consisting of a set of drift chambers and of 
a timing counter embedded in a strong gradient magnetic 
field generated by a superconducting magnet (COBRA) 
for the measurement of e+ kinematic variables. A sketch 

^ Present address: DEGTRIS Ltd., Neuenhoferstrasse 107, 
GH-5400 Baden, Switzerland 



of the apparatus is in FigjT] The waveforms from readout 
electronics are digitized at ~ 1 GHz frequency and stored 
in the output to optimize time resolution [1 . 
Waveform data is encoded in a format developed in the 
MEG group. The data of each channel consists of a header 
and binary waveforms. Each header contains a hardware 
channel number and parameters needed to decode data. 
The data can be encoded in different ways depending on 
required compression factor, precision and characteristics 
of waveforms of each subdetector. The experiment totals 
~ 3000 channels and reduction by a factor of 3 in data 
size is achieved applying zero suppression, waveform re- 
sampling or restricting the recorded region depending on 
the subdetector. 

The typical DAQ event rate is ~ 6 Hz. Data size is about 
4.8 GB per run for 2000 events. Data files are compressed 
in the offline-cluster by a factor of 2. Event size after the 
compression is 1.3 MB /event. 

During ^ 3 months in 2010, ^ 21 x 10^ /i+ e+7 trig- 
gers were collected for a total of 60 TB of data written 
on disk, half of which from physics runs and the rest from 
calibration runs. 

The software requirements include the simulation of the 
generation of signal and background events, of their inter- 
action with the detector and of the read out, the recon- 
struction from raw data, real or simulated, to high level 
objects, e.g. tracks and photons as well as providing an 
analysis environment. 

The average time for simulating the interaction of a signal 
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event in the detector is 5.8 s/event, while the average time 
for simulating the readout electronics is 1.2 s/event. The 
average time for reconstruction is 1.6 s/event. 
The software organization designed to comply with these 
requirements is presented. 



COBRA Magnet 

\ Drift Chamber 




Fig. 1. The MEG experimental setup. 



2 The MEG software structure 

The MEG offline software consists mainly of GEM (event- 
generation, particle tracking and detector simulation), Bar- 
tender (event-mixing and electronics simulation) and An- 
alyzer (recostruction and analysis of experiment and sim- 
ulation data). The relations between the various software 
components are shown in Fig. |2j 

The parameters in use in the programs are managed through 
a common SQL database. 

The MEG DAQ system is based on MIDAS [2 ; raw ex- 
perimental data are therefore saved as binary files in the 
native format of the system. Briefiy the MIDAS format 
consists in an event header followed by MIDAS banks. 
Each bank is defined by a 4 character name and contains 
a description of the unique data type and an array of data. 
The DAQ system inserts run information and default anal- 
ysis parameters into the database when a run is taken. 
These files are read by Analyzer that reconstructs the 
events and produces two files: a rec ROOT [3], [4] file. 



which contains a ROOT Tree and a histogram file for 
quick data checks. Before Analyzer starts a run, analysis 
parameters are read from the database. The analysis pa- 
rameters (geometry, calibration etc.) can be changed later 
by users and data can be reprocessed with the updated 
parameters. If necessary. Analyzer copies raw data of se- 
lected events (cut for physics analysis) into raw ROOT 
files for future reprocessing. 

The simulation program GEM, steered by configuration 
files created by the DB2Cards program by reading the 
database, generates various types of events that are propa- 
gated in the detector. It is based on GEANT3 and CERN- 
LIB and outputs data in exchange ZEBRA format [5 . 
Bartender reads those files and simulates the readout elec- 
tronics to convert hits into waveforms. The simulated wave- 
forms are written in raw ROOT files whose bank structure 
is the same as experimental data in MIDAS files. In sim 
files simulation specific variables, such as kinematics of 
generated particles and true hit information, are saved. 
Analyzer reconstructs events from raw files using the same 
algorithms as for the experimental data. High level physics 
analysis is also realized within Analyzer. 
Version control is managed by the Subversion [6 package. 



3 REM: a FORTRAN 77 framework 

As anticipated above, the technical choices in designing 
the offline architecture were driven by considerations about 
the time schedule, the man power and the technical skills 
available in the collaboration at the start of the project. 
The existence of important fragments of simulation code 
developed in FORTRAN 77 and GEANT3 during the pro- 
totype phase at the time of the choice motivated the col- 
laboration to retain the programming language and the 
library for the simulation of the experiment. 
Nevertheless the simulation software was organized fol- 
lowing a modern programming paradigm, that is using an 
Object Oriented approach organized in a framework [7]. 

3.1 Implementation of a FORTRAN 77 framework 

The detector simulation section GEM of the MEG soft- 
ware is written in FORTRAN 77, that was designed for 
procedure oriented structured programming, not for 00 
programming. 

Nevertheless a programming paradigm can be implemented 
in a variety of programming languages, even not designed 
for it. A limited but satisfactory support to the 00 paradigm 
is at reach also in FORTRAN 77 on the basis of the fol- 
lowing list of approximate equivalences between procedure 
oriented and 00 concepts 

— Class ^ Library 

— Class data ^ Data structure (FORTRAN 77 Common 
block) 

— Class interface ^ Set of library routines 

— Base Class ^ Module standardization 

— Virtual Class ^ Alternate choice of libraries 
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Fig. 2. Connection between MEG software components 



3.2 Modules 

The Module is the basic unit manipulated by the frame- 
work that corresponds to an 00 class. Each Module is 
implemented concretely in a library. There are different 
types of Modules, that can be classified as 

— Basic Module : empty Module 

— Steerable Module : Module steerable by configuration 
files (cards) 

— Data Module : contains only data 

— Algorithm Module : implements an algorithm using 
other Modules 

— Service Module : provides interface to external libraries 

These types share a common set of routines and dif- 
fer by additional functionalities depending on the Module 
type implementing the 00 paradigm of class hierarchy. 

3.3 The framework: REM 

The framework is a Module with an event loop. The Mod- 
ules associated to the framework are accessed in sequence 
by calling their routines in the corresponding framework 
routines. 

Three module are provided by default in REM 

— Steering cards: FFREAD package 

— I/O : ZEBRA I/O 

— Histogramming : HBO OK package 

The others Modules are project dependent and their 
routines are called in the corresponding framework user 
routines. These user routines, provided empty by default, 
are called by the framework routines. They can be over- 
written implementing the 00 inheritance mechanism. 



4 GEM: the Monte Carlo simulation 

The propagation of the /i+ beam in the last section of 
the beam line, its interaction in the target, the particle 
decay and the propagation and interactions of the decay 
products in the detector are simulated with a FORTRAN 
77 Monte Carlo program (GEM) based on the GEANT3 
package [8 . GEM can generate several event types, such 
as /i+ e+7 signal (shown in the Fig. [3|, radiative muon 
decay, Michel muon decay, cosmic ray, alpha source cal- 
ibration and many others. GEM incorporates a detailed 
description of the material and simulates the interactions 
of the particles in the detector as well as the response of 
the sub-detectors up to the readout stage. In particular 
the photon propagation in the Liquid Xenon Calorimeter 
and in the Timing Counter is simulated in detail. 
The program is heavily modularized using the FORTRAN 
77 framework REM. This approach simplifies the addition 
of new Modules; Modules can be either sub-detector sim- 
ulation sections or service tools like e.g. graphics. 
Within this approach, the GEANT3 library can be treated 
as a Module and sequenced like any other module. 
GEM is steered by configuration files, called cards, read 
by the FFREAD package [9], that is available in REM. 
These cards can be generated through the DB2Cards that 
is a ROME based framework. DB2Cards reads parame- 
ters from the database and output FFREAD cards, one 
for each Module, under the control of a XML configura- 
tion file. This file permits to select the simulation configu- 
ration, e.g. year dependent or calibration setups, that are 
maintained in the database. 

The most natural choice for the format of the GEM output 
files is ZEBRA. Potential disadvantages of this approach 
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are that the manipulation of ZEBRA banks is not user 
friendly, error prone and requires significant knowledge 
of the package. A solution to these problems consists in 
manipulating only variables in common blocks in the code 
and then mapping these variables into the output ZEBRA 
banks. That is done automatically by providing a bank de- 
scription based on the DZDOC format [5 and generating 
through a Perl [iO^ script the following routines for each 
bank xxxx 

get_xxxx Fetch the bank link 

print _xxxx Print out of the bank 

build_xxxx Fill the bank with the variables in common 

block (before writing out) 
filLxxxx Fill the common block variables with bank 

content (after reading in) 

GEM provides for each Module yyyy the routines fill (build) 
and fill (build) yyyyeve that call all corresponding rou- 
tines of the banks related to the module. GEM provides 
also the routines f ill (build) gemrunheader and fill (build^ 
that call the corresponding routines for all the Modules. 
The buildgemrunheader is called once per run and buildgeme 
is called once per event to build the banks from the vari- 
ables in common blocks before calling the I/O ZEBRA 
routines in REM. 




5 The database 

Run dependent information such as geometry, calibrations 
and analysis parameters are stored in a relational database, 
used for the DAQ frontend, analysis and simulation. On- 
line data logger inserts an entry into the database im- 
mediately when a run is taken. A run can be processed 
by Analyzer with the default settings and reprocessed 
later with improved calibration constants after modify- 
ing the database. For simulation, the dedicated program 
DB2Cards reads the database and write the FFREAD 
cards required by GEM for all the configurations required. 
Therefore all packages use consistently a common database. 

For the main database, MySQL [11 is used so that 
clients can connect over the network. Daily snapshots are 
taken in MySQL script format and SQLite[12 format. 
SQLite is a single file database; therefore it can be used 
without network, and can be used for test purposes by 
modifying local copies without affecting other users. In- 
formation on all the runs and all the simulation config- 
urations are stored in the database. The MEG database 
consists of a few hundreds tables and each has a direct or 
indirect relation to the mother table RunCatalog so that 
a run number suffices to retrieve all the information, and 
no recompilation or manual modification of configuration 
files is required to analyze any run sample. At May 2011, 
the size of the MySQL database is ^ 500 MB. 



6 ROME: a framework generator 

ROME [13], [H] is a ROOT based framework generator for 
event based data processing. It has been developed in the 



Fig. 3. A /i^ e^7 simulated event: the track is in 
red with hits in drift chambers and timing counter in violet, 
red and blue, the 7 track in blue with hits in Liquid Xenon 
Calorimeter in cyan. 



MEG collaboration but has been designed as a general- 
purpose software so that it can be used for other experi- 
ments too. 

The key concept of ROME is to generate most of the 
code of a project, except the analysis (or simulation) al- 
gorithms. 

In general, data processing software consist of three parts: 
the first is a project independent part such as e.g. user 
interface, handling of the event loop. The second is a 
project dependent part, which can be summarized in a 
compact way such as e.g. data structure and calling se- 
quence of algorithms. The third is a completely project 
dependent part such as e.g. the implementation of analy- 
sis algorithms. 

Figure [4] shows components in the ROME environment. In 
this environment, the first part is included in the ROME 
package, and also the ROOT infrastructure is used. For 
the second part, a programmer describes the framework 
for his/her experiment in a clear and compact way in a 
XML definition file. Out of this file, ROMEBuilder program 
generates all experiment specific classes and modifies the 
framework. It calls also make command after the source 
code generation; therefore the build procedure shown in 
Fig. 4]- (a) can be done with a single command. For the 
third part, a programmer adds the algorithm code to the 
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pre-generated methods. Further modifications can be done 
by editing the definition XML file or by modifying algo- 
rithm implementations, then running ROMEBuilder again. 
Because of the generation scheme, amount of hand written 
code becomes smaller, and it becomes possible to start or 
modify software without learning complicated implemen- 
tation of the framework. 

The generated framework is linked with the ROOT li- 
braries; therefore all ROOT classes are available for the 
analysis. Additional classes written by hand can be also 
linked. The generated program is steered using a configu- 
ration XML file at the run time. Interactive control of the 
program, for example pausing the event loop and ploting 
histograms, is possible. 




(a) (b) 

Fig. 4. Components in the ROME environment (a) at build 
time, and (b) at run time. 



The following list is part of the items automatically 
generated by ROME according to a XML definition file. 

— Data classes (Folders), with a complete set of meth- 
ods. 

— Algorithm classes (Tasks) with empty methods to be 
filled by a programmer. 

— Visualization classes (Tabs) with empty methods to be 
filled by a programmer. 

— Data input classes to read user defined data files with 
empty methods to be filled by a programmer. 

— Code to create and write histograms. The histograms 
can be filled in user code. 

— Code for I/O of TTree^into files. 

— Code to read and write configuration XML files. 

— Code to read and write SQL database. MySQL, Post- 
greSQL [15 and SQLite are supported and switchable 
by a configuration file at run- time. 

— Code to read MIDAS format files and to connect to 
MIDAS Online Database System (ODB) to access on- 
line data. 

— Makefile is automatically generated or updated when 
new classes are defined by a definition XML. 

— HTML document where description of Tasks and that 
of each variable in Folders are written. ROOT style 



^ TTree is the ROOT implementation of the data structure 
tree concept 



document, like "reference guide" in ROOT web page 
can be also generated for user code. 

ROME implements the organization commonly used 
in 00 applications in high energy physics [16]: data ob- 
jects^ whose function is to store data, are separated from 
algorithm objects^ whose function is to incorporate algo- 
rithms. 

The former are implemented as a Folder class, the lat- 
ter as a Task class. Tasks are derived from ROOT TTask; 
therefore recursive calling sequence is realized. ROME Folders 
are derived from ROOT TObject (not from TFolder), and 
they can be filled into ROOT TTree as a single object or 
as an array in ROOT TClonesArray. 
For Folders, ROME generates not only the class itself, 
but also modifies the part of the framework related to the 
Folder such as allocation and initialization, adding or set- 
ting address of a branch in a TTree for writing (reading) 
the Folder to (from) a file, filling variables by reading the 
database at the beginning of a run (if required in XML). 
A definition of a Folder reads like a XML document 
shown in Fig. [5] together with part of C-f-H- code gener- 
ated by ROME according to the definition. This Photon 
instance has two variables. Energy and Time. The gener- 
ated class has these variables as its data members, and 
Set and Get methods are defined. The framework gener- 
ates automatically, for example, 10 instances (the number 
can be fixed or variable) at the beginning of the program 
and those instances are available in the user code out-of- 
package. For example, GetPhotonAt () and GetEnergyO 
shown in Fig. |6] are generated according to the description 
in the XML definition file of the Folder without manual 
programming. Any types of Field, both fundamental and 
derived, can be added in the Folder structure as far as it 
is supported by ROOT dictionary generation (dictionar- 
ies are needed for TTree I/O or socket connection over the 
network) . 

A definition of an algorithm object, that is a Task, 
reads like a XML document shown in Fig. |6] According 
to the definition file, ROME generates header and source 
files. A generated source file has empty methods, and a 
programmer can implement analysis in it immediately. As 
an example, in the code in Fig. [6j a few lines to access a 
Folder are added to the generated file. ROME generates 
not only the task class itself, but modifies framework to 
call it in an order specified in the definition XML. In this 
example, a configuration parameter DebugPrint can be 
changed using a configuration XML file at run-time with- 
out re-compile. A function call GetSP()->GetDebugPrint () 
shown in the example code is available without any man- 
ual programming, and a field to configure the parameter 
automatically appears in a configuration XML file after 
the first use of the file. 

The framework outputs one or more TTrees. A pro- 
grammer can define Trees and add Folders to it as branches 
in a XML description file. The framework code is auto- 
matically modified; therefore no manual programming is 
needed to add branches to be read or written. Figure [7| 
shows an example of Tree structure. 
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<Folder > 
<Folder 
<Arr 
<Fie 
< 
< 
< 

</Fi 
<Fie 
< 
< 
< 

</Fi 
</Folder> 



Nam 
ayS 
ld> 
Fie 
Fie 
Fie 
eld 
ld> 
Fie 
Fie 
Fie 
eld 



e >P/ioton</ Folder Name > 
ize>10</ArraySize> 

IdName > E'ner^?/< / FieldName > 
ldType> L)o'iz?)/e_^</FieldType> 
IdComment > E'ner^?/ of a photon</F : 
> 



IdName > rzme</FieldName > 
ldType> L)o^6/e_^</FieldType> 
IdComment > Tzme of a photon</ F±el^(!f.C6^i^en%,> 
> 



<Task> 

<TaskName > Photon An alysis</TaLs'k.'iilaLme > 
<SteeringParameters > 

<SteeringParameterField> 

<SPFieldName >De6iz^Prmt</SPFieldNam^ > 
<SPFieldType> 5oo/_t</SPFieldType> 
1 dC omms^B^lS* e e r i ngP ar am e t e r F i e 1 d > 

</ Steer ingParameters > 
</Task> 



class MEGPhoton : public TObject 

{ 

protected : 

Double_t Energy; // Energy of a photon 
Double.t Time; // Time of a photon 



public : 

MEGPhoton(Double_t EnergyV=0, Double.t Time 
virtual ~ MEGPhoton () ; 

Double.t GetEnergyO const 

{ return Energy ; } 
Double.t GetTime() const 

{ return Time ; } 
void SetEnergy ( Double.t Energy. v) 

{ Energy = Energy_v ; } 
void SetTime ( Double.t Time.v) 

{ Time = Time.v; } 

}" 



Fig. 5. An example of Folder definition in a XML file (upper) 
and part of the C++ code generated by ROME (lower). 



C6iiLment> 

void MEGTPhotonAnalysis : : Init () 

{ 
} 

void MEGTPhotonAnalysis : : BeginOf Run () 

{ 
} 

void MEGTPhotonAnalysis :: Event 



{ 



if (GetSP()->GetDebugPrint ) { 
-O);for (int i=0;i<10;i++) { 
cout 

«gAnalyzer— >GetPhotonAt ( i)— >GetEnerg3/ 
«endl ; 

} 

} 



} 



void MEGTPhotonAnalysis : : EndOf Run () 

{ 
} 

void MEGTPhotonAnalysis : : Terminate () 

{ 
} 







Output files can be used for interactive analysis, and fur- 
ther analyzed by ROOT macros. 

Output files of each step can be used as input files of 
the following step; therefore the analysis can be separated 
into several steps. For example, in the analysis of MEG, 
we can save results of waveform analysis, which is the most 
time-consuming in the chain, and perform reconstructions 
on this file to improve the algorithm many times without 
redoing the waveform analysis. 

An interactive mode, which is almost the same as ROOT 
interactive mode, is also provided. In the interactive mode 
or in macros, experiment specific classes are also available 
in addition to the standard ROOT classes. 
ROME also generates a HTML document and a Makefile. 
The generated framework is already compilable just by 
make command and, after that, is executable. 
The generation mechanism is used not only at the begin- 
ning of the project, but also during the code development. 
For example, a programmer can easily add a new configu- 



Fig. 6. An example of Task definition in a XML file (upper), 
and part of the C++ code generated by ROME (lower). 



<Tree> 

<TreeName>£)atarree</TreeName > 
<Branch> 

<BranchName > P/ioton5ranc/i</ Br anchName > 
<RelatedFolder >P/ioton</RelatedFolder > 
</Branch> 
</Tree> 



Fig. 7. An example of Tree definition in a XML file. 
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ration parameter to an existing Task, or add new variables 
to a Folder. Code in the framework is automatically mod- 
ified consistently. 

MEG Analyzer consists of about 200 Folder classes and 
100 Task classes. The total number of lines in the Ana- 
lyzer code is more than one million. 84% of them are either 
generated by rootcint [3 or ROME, or included in the 
ROME package, while the rest were written manually. 



7 Readout simulation and event mixing 

Following the detector simulation and before the recon- 
struction and analysis program an intermediate program, 
called Bartender, is required for the processing of Monte 
Carlo data. This program serves different roles: 

— Conversion of ZEBRA files into ROOT files 

— Readout simulation 

— Event mixing 

It reads the GEM output ZEBRA files calling fillgemrunh 
once per run and f illgemeve once per event after calling 
the I/O ZEBRA routines to fill the variables in FOR- 
TRAN common blocks from the banks. These variables 
are finally mapped to C++ classes manually. 
Simulation specific data such as kinematics of generated 
particles, true hit information, etc. can be streamed in a 
sim Tree in separate ROOT files for further studies. 

It simulates detector readout electronics and produces 
waveforms. For example, the Liquid Xenon Calorimeter 
waveforms are obtained by convolution of single photo- 
electron response of a photomultiplier tube (PMT) with 
hit-time information of scintillation photons simulated in 
GEM. PMT amplification, signal attenuation, saturation 
of the readout electronics, noise, etc. are taken into ac- 
count. Simulated waveforms are encoded in the same man- 
ner as the experimental ones and written in a raw Tree in 
ROOT files. 

It makes a mixture of several sub-events; rates of each 
event type are set with a configuration file. To study the 
combinatorial background events, sub-events are mixed 
with various relative timing with respect to each other 
and with respect to the trigger. For instance random and 
fixed timing can be selected. That allows simulating many 
different pile-up configurations with a limited number of 
samples of events simulated through the detector. 



In the first step, raw data are read and calibrations are ap- 
plied to waveforms. In the second step, waveform analysis 
specialized for each sub-detector are performed to extract 
time and charge of pulses. Waveforms are also used to 
identify pileup events and for particle identifications. 
In the third and last step, events are reconstructed using 
algorithms implemented by experts of each sub-detector. 
Several different algorithms are implemented to recon- 
struct each kinematic parameter for crosschecks. Each Task 
may have a dedicated Folder to write its result. Tasks 
share a Folder to hold results of a standard choice among 
those algorithms; this choice is specified by a configuration 
file. Tasks are executed in the same process and results are 
written in an output file together. 

Figure [S] shows a reconstructed experimental event. 




Fig. 8. A /i^ e^7 reconstructed event and closer views. 
Reconstructed hits in drift chambers and timing counters, a 
positron track and a 7-ray are shown. Color-code of Calorime- 
ter PMTs represents output of each PMT. 



8.2 Visualization 



8 The reconstruction and analysis program 

Analyzer incorporates multiple purposes: event reconstruc- 
tion, visualization, computation of calibration constants 
and physics analysis. 



8.1 Event reconstruction 

Analyzer consists of several Tasks for each step of analy- 
sis; each Task can be switched on/off. 



Data quality is monitored for various time-spans: event- 
by-event, run- by-run or in days. 

For event-by-event monitoring, several displays are im- 
plemented. Figure [9] shows one of them. The displays show 
waveforms, status of trigger, reconstructed hits and tracks 
and any other information useful for monitoring. Those 
displays are used for both online and offline. When it is 
used for online monitoring. Analyzer and DAQ run in par- 
allel and data are transferred over a socket connection. 
Hard copies of the displays are saved periodically for re- 
motely monitoring using web-browsers. 

Two types of portable document format (PDF) files 
are automatically prepared by macros, which read his- 
togram files made by Analyzer. The first type shows his- 
tograms to describe the run and is made automatically for 
each run soon after the run is finished. The second type 
shows strip charts to monitor time variations of the status 
of the detector and of the electronics in a day or a week. 
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Fig. 9. A graphical display of timing counter hits, waveforms. 
A reconstructed positron track is also shown. 



8.3 Calibration 

Analyzer is used also to compute calibration constants 
(photomultiplier gains, time-offsets, etc.). Each calibra- 
tion constant is associated to a Task. The calibration Tasks 
are usually run on events already processed with a prelim- 
inary set of calibration constants. The updated calibration 
constants can be made available in a variety of format: his- 
tograms, text file or SQL macro. They can be stored in the 
database, and used in the next round of reconstruction. 

8.4 Physics analysis 

Event preselection and blinding for physics analysis, de- 
scribed in section |9| are implemented in Analyzer. On 
events in the analysis region, likelihood analysis is per- 
formed to calculate the best estimate of the number of 
/i+ e+7 signal candidates, its confidence interval and 
the significance. The 90% confidence interval of the num- 
ber of signal events is calculated using the unified ap- 
proach [17 . We made independent likelihood analysis tools 
with different statistical methods or parametrization of 
probability density functions for cross checks. 

9 Offline processing 

Just after a run is taken, a raw data file written in the 
MIDAS format is sent to the offline-cluster, and a process 
to analyze it automatically starts. The MIDAS files are 
compressed and stored on tapes. The compressed MIDAS 
files and rec files of calibration runs are accessible for fur- 
ther studies, while a special treatment is done for the data 
of physics runs. 

MEG has adopted the principle of 'blind' analysis in search- 
ing for /i+ e+7 signal. That means that the events with 
kinematic parameters closest to the expected signal (in the 
'blinding box') cannot be used for determining the anal- 
ysis parameters (e.g. the cuts or the probability density 



functions) to avoid biasing the analysis. In order to guar- 
antee that, the data in the 'blinding box' are inaccessible 
during the first phase of the analysis. 
This concept is realized in Analyzer with Tasks streaming 
the events into different ROOT files depending on the se- 
lection criteria they satisfy. 

A first round of processing operates a pre-selection on 
coarsely calibrated data with loose cuts that are streamed 
in: 

selected Events passing the pre-selection 
unselected Events not passing the pre-selection 
unbiased All calibration trigger events and every fifti- 
eth physics-trigger event 
Trees containing raw waveforms are produced for 'se- 
lected' and 'unbiased' events in this step. The 'unbiased' 
samples are used for monitoring of the experiment and for 
the calibrations. The 'selected' events are not accessible. 
After the calibrations are finalized, reconstruction is per- 
formed on the 'selected' samples using raw files. At the 
end of this step, another Task applies tighter cuts defin- 
ing the 'blinding box'. The events are streamed into the 
files: 

blind Events preselected in the 'blinding box', 

candidate to be signal 

open Events preselected but outside the 'blind- 

ing box' 

and 'selected' files are deleted. The 'blind' files are made 
accessible only when the analysis is finalized. 

10 Conclusion 

Software is a crucial component of any experiment and its 
power and flexibility is a key ingredient of its success. 
MEG had the challenge to design a software structure that 
could strike a balance between flexibility and user friendli- 
ness. The limited size of the offline architecture group and 
the requirement that a large fraction of the collaboration 
could contribute to the programming of the algorithms, 
have led to greatly emphasize the use of known packages 
as well as the shielding from the average programmer of 
I/O handling, format conversion and Object Oriented pro- 
gramming into the frameworks. 

A mixed language environment with two separate frame- 
works, one for each environment, proved to be success- 
ful. It relies heavily on standard software elements like 
GEANT3, ZEBRA, FFREAD in the simulation section 
implemented in FORTRAN 77; XML, ROOT in the rest 
of the code implemented in C++; MySQL and SQLite for 
the database. 

This configuration allowed the implementation of all ex- 
perimental requirements within the tight time and man- 
power constraints, such to support the physics analysis 
first published in [18]. 
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